1. Technical Field
The present invention relates to assembling information processing applications, and more particularly, to a method and system for automatically assembling processing graphs in information processing systems.
2. Discussion of the Related Art
Generally, software applications achieve a desired processing outcome at the request of a person or agent by using a collection of reusable software components assembled to achieve the outcome. When a request must be accommodated and no suitable application exists, the requestor can cobble together a solution by collecting partial solutions from existing applications, doing some additional manual work to complete the task. However, new or adapted applications are generally needed; thus, requiring the initiation of a human process to accumulate application requirements and to develop/adapt/assemble applications that can achieve the desired outcome. A challenge arises in understanding the processing request, understanding the components that might achieve the desired outcome, and knowing how to build and/or assemble the components to achieve the processing outcome and fulfill the request.
Expressing desired processing outcomes directly as computer programs coded using general-purpose languages such as C++ or Java generally requires long development cycles and imposes high maintenance costs for any new type or variant of information processing outcome. Casting such requests as traditional queries can reduce some of the costs and delays by providing a simpler means of expressing and applying complex data transformations, etc. However, these query-oriented approaches do not offer sufficient coverage for a wide variety of requests involving non-query goals or requests for outcomes involving operations on unstructured data (e.g., speech-to-text and image recognition operations), nor are they resilient in the face of modifications to underlying conceptual schemas.
Both of the programming approaches and the query approaches suffer from an absence of an explicitly declared intent. In other words, they do not explicitly denote the intent of the outcome requested, with instead the intent being implicit and often only present in the minds of software developers. Thus, any adjustments to either the requested outcome or the underlying conceptual schemas can become challenging and costly, often requiring developers to “reverse engineer” existing applications in an attempt to harvest the original intent in order to adapt to the modifications.
Further, in such approaches, the requestor of the processing outcome must generally know some potentially large amount of detail as to the means of fulfilling the request. For example, programmers need to know specific steps to be taken and query writers need to know the structure of tables and the details of the operation composition to produce just one approach, representing only one approach to fulfilling the request. If there are many possible means of satisfying a request, the users must also know which way is best, under what circumstances, and the circumstances under which their solutions are to be used.